1. Field
This application relates to communication networks and, more particularly, to a method and apparatus for implementing link-based source routing in generic framing protocol.
2. Description of the Related Art
Data communication networks may include various computers, servers, hubs, switches, nodes, routers, proxies, and other devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as frames, packets, cells or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, and how protocol data units should be handled or routed through the network by the network elements.
To enable packets and frames of different protocols to be transported over a physical layer (layer 1) protocol such as T1, DSL, or SONET/SDH, a generic framing procedure has been developed. The Generic Framing Protocol (GFP) which defines the generic framing procedure specifies a GFP frame format that has a core header which specifies the length of the payload, and a payload area which may contain one or more client protocol frames/packets to be transported on the network. In frame-mapped GFP, a given client protocol frame/packet such as an IP packet or Ethernet Frame will be loaded into the GFP payload. In transparent GFP, a fixed number of client characters are mapped into a GFP frame of predetermined length. Several attractive features of GFP are that GFP is able to carry client protocol data units across the transport network without requiring modification of the client headers and that it may be used to carry multiple different types of traffic without notifying the underlying network what type of traffic is being transported.
When GFP frames are multiplexed into a SONET/SDH channel (STS-n) by an external packet source, the amount of bandwidth filled on the network core is limited to the size of the channel at the multiplexer. For example, FIG. 1 illustrates an example in which GFP frames are multiplexed by an external packet source 10 with a GFP multiplexer 12 onto an STS-n channel 14. Since the STS-n channel cannot be combined with other STS-ns without demultiplexing and remultiplexing the protocol data units, the STS-n channel will remain at the current fill level on the network even after passing through optical cross connects 16 and other network elements.
To increase fill on the network, it is possible to multiplex the GFP frames onto a SONET/SDH channel by including a GFP multiplexer 18 in the optical cross connect 20 and bringing GFP frames to the optical cross connect without multiplexing the frames onto an STS-n channel. In this manner, additional GFP frames may be placed on the same STS-n to increase the fill level on the STS-n channel.
Another way to increase the fill level is to de-multiplex the GFP frames from the STS-n channels, switch/route the packets to an appropriate STS-n, and then re-multiplex the packets onto a new STS-n channel. An example of this is illustrated in FIG. 3. As shown in FIG. 3, when packets arrive they pass through an optical cross connect 22 to a GFP demultiplexer 24. The de-multiplexer terminates the original GFP frame flows and passes the packets or frames extracted from the GFP frame to a layer 2/3 switch/router 26. After the frames are switched/routed, the frames are passed to a GFP multiplexer 28, multiplexed onto a new STS-n channel, and passed onto the network over the new STS-n channel.
Handling GFP frames in this manner is not trivial, however, since the GFP frames may be carrying protocol data units formed using any number of different protocols. Thus, extracting the client protocol data units, reconstructing the client protocol data units, and performing routing using the protocol headers associated with the client protocol data units is not a trivial matter. It also represents a potential security lapse that may be unacceptable in particular contexts. Thus, extracting client protocol data units and performing routing based on the payload is at best very difficult and, at worst, defeats one of the purposes of GFP, which was to simplify transport of numerous different protocols across a network in a transparent manner.
Although a proposal has been made to add a new extension header type to GFP, which would allow the GFP frame to carry a label to allow the frame to be switched along a label switched path, the proposal requires state information to be distributed to network elements on the network, in a manner similar to Multi Protocol Label Switching (MPLS), to enable the labels to be used to forward the packets on the network. The state information, according to the proposal, would instruct the network elements as to the ingress/egress port/label relationship and would be distributed on the network via a signaling protocol. While this solution might be operable, it is a relatively intrusive way of enabling GFP frames to be switched on the network, since it requires state information to be distributed and maintained on the network elements throughout the network. Additionally, this solution also may experience problems with scaling as the number of nodes on the network increases and the level of traffic on the network is increased. Accordingly, it would be advantageous to provide a scalable way to switch GFP flows on a SONET/SDH network.